The use of these devices is becoming widespread. With the rise of the GUI (and the increased availability of programming tools and languages to the general populace), this trend can only be expected to continue.
It should be noted that destructive devices can be a security risk for small networks or single servers. If your box is hooked up via Ethernet with a fast connection and you have only one mail server, an e-mail bomb attack on one of your users could temporarily grind your machine to a halt.
NOTE: The average high school student now has access to C, C++, Pascal, BASIC, and so on. School policies are usually very strict about students copying such software, but most youngsters pay little attention. I have a client in Los Angeles whose son has built an enormous collection of programming tools. He obtained all those programs at his high school. (Young college students get these software products legally, perhaps, but at the greatly reduced rate for educational institutions. Therefore, they have ready access, irrespective of how they acquire such tools.)
I have chosen to highlight four key utilities within the destructive device class:
Figure 14.1.
The Up Yours mail-bombing program.
Version 2.0 of this utility was released sometime in March 1997. This bomber runs only on the Microsoft Windows platform. As you might expect, the tech support is wanting, but the program is free nonetheless. If you are a system administrator, you will want to scan your local drives for the following files:
upyours.exe upyours2.zip upyours3.zipIf these files appear in a user's directory, there is a strong likelihood that he is about to e-mail bomb someone (of course, perhaps he simply spends his time collecting hacking and cracking programs). In any event, the utility is hard to find. If one of your users has acquired this program, he clearly has an interest in hacking or cracking.
Figure 14.2.
KaBoom!
This utility works quite well, but the interface is poorly programmed. (For example, the main list window presents the lists as selectable from check boxes. This is shoddy work. The programmer could have saved time and space by running them through a list box instead. It takes a lot of work using this utility to link the target to any significant number of lists; the bombing party is forced to scroll down to obtain more lists.)
NOTE: List linking is a rather insidious activity and a not-so-subtle form of harassment. It works like this: On the Internet are mail servers that distribute mail messages collected from various sources. These messages invariably concentrate on a special-interest subject (the subject of security, for example). These mail servers (sometimes called list servers) collect such messages and mail them to members of the list on a daily, weekly, or monthly basis. Members can subscribe to such a list in several ways, though most commonly through e-mail. When I say that a target has been list-linked, I mean the target has been subscribed (without his consent) to one or more mailing lists. This is usually done with a tool like KaBoom. Such tools submit registration requests on behalf of the victim, forging his e-mail address.
In any event, this utility's signature files are these:
kaboom!3.zip kaboom3.exe
Figure 14.3.
Avalanche.
The signature files for this product are
TIP: The programmer here was a bit absentminded. The program was written at least in part in Microsoft Visual Basic 4.0. As such, there are a series of DLL files that are required to run the application. These are missing from the general distribution of this utility; therefore, serious bombers must go out onto the Internet to retrieve those files (one is OC2.DLL). Because of this, I would estimate that Avalanche is probably used less than its counterparts, even though its overall design is superior. Inconvenience discourages most users of this particular ilk.
alanch10.zip avalanche20.zip avalanche.exe
Figure 14.4.
The Unabomber.
The signature files for this utility are
unabomb.zip unabomb.exe
Figure 14.5.
eXtreme Mail.
The signature files for this product are
xmailb1.zip xmailb1.exe
homicide.zip homicide.exe
#!/bin/csh # Anonymous Mailbomber # do chmod u+rwx <filename> where filename is the name of the file that # you saved it as. #*** WARNING - THIS WILL CREATE AND DELETE A TEMP FILE CALLED # "teltemp" # IN THE DIRECTORY IT IS RUN FROM **** clear echo -n "What is the name or address of the smtp server ?" set server = $< #echo open $server 25 > teltemp echo quote helo somewhere.com >> teltemp #The entry for the following should be a single name (goober), #not goober@internet.address. echo -n "Who will this be from (e.g. somebody) ?" set from = $< echo quote mail from: $from >> teltemp echo -n "Who is the lucky recipient (e.g. someone@somewhere) ? " set name = $< echo quote rcpt to: $name >> teltemp echo quote data >> teltemp echo quote . >> teltemp echo quote quit >> teltemp echo quit >> teltemp echo -n "How many times should it be sent ?" set amount = $< set loop_count = 1 while ($loop_count <= $amount) echo "Done $loop_count" ftp -n $server 25 < teltemp @ loop_count++ end rm ./teltemp echo $amount e-mails complete to $name from $from@$server # -------------------- # MailBomb by CyBerGoAT
Basically, Bombtrack is another run-of-the-mill bombing utility, widely available at hacker sites across the Internet. The signature file for this application is
bombtrack.bin
flamethrower10b.sit.bin
If you maintain a site and malicious users from the void start bombing you, contact their postmaster. This is usually quite effective; the user will be counseled that this behavior is unnecessary and that it will not be tolerated. In most cases, this proves to be a sufficient deterrent. (Some providers are even harsh enough to terminate the account then and there.) However, if you are faced with a more difficult situation (for example, the ISP couldn't care less if its users bombed the Internet collectively), you might have to take more aggressive measures.
One such measure is to block traffic from the originating network at the router level. (There are various packet-filtering techniques that you can apply.) However, if this doesn't suit your needs (or your temperament), there are other, more proactive solutions. One fine technique that's guaranteed to work is this: Fashion a script that catches the offending e-mail address each time it connects to your mail server. For each such connection request, terminate the connection and autorespond with a polite, 10-page advisory on how such attacks violate acceptable use policies and that, under certain circumstances, they may violate the law. After the offending party has received 1,000 or so returns of this nature, his previously unconcerned provider will bring the offender onto the carpet and promptly chop off his fingers.
There are renegade providers around, and there is absolutely no reason that you cannot undertake such action. After all, you have done no more than refuse the connection and issue an advisory. It is hardly your fault if the warning was not heeded. Notwithstanding various pieces of legislation to bring the Internet into the civilized world, it is still much like the Old West. If another provider refuses to abide by the law and generally accepted practices, take it down to the OK Corral. One last point here: To make this technique especially effective, be sure to CC the postmaster of the bomber's site with each autorespond message.
NOTE: These aggressive techniques can only be implemented in the event of a garden-variety mail-bombing situation. This will not work for list linking because list linking is a process that obscures the true origin address of the attacker. The only way to obtain that address if is the list owner (whoever is responsible for the mailing list server) runs logging utilities and actually keeps those logs.For example, suppose the list accepts subscription requests from a Web page. It can easily obtain the address by checking the HTTP server connection log (this file is normally called access.log). HTTP servers record the originating IP address of each connection. However, the large majority of lists do not accept subscription requests through their Web pages. Instead, they use garden-variety mail. The percentage of system administrators who heavily log connection requests to their mail server is fairly small. Moreover, to trace the attacker, you would need help from more than just the system administrator at the mail list site; suppose the attacker was using a dial-up connection with a dynamically allocated IP address. After you acquire that IP from the mail-list system administrator, you must convince the attacker's ISP to cooperate by forwarding its logs to you.
Furthermore, unless the attacker's ISP is running good logging utilities, the logs you receive will only demonstrate a list of possible suspects (the users who were logged to that IP or dial-up at the hour of the attack). Even more research may be required. For this reason, list linking has become far more popular than run-of-the-mill mail bombing.
In this respect, IRC is different from any other networked service on the Internet. IRC is grass roots and revolutionary Internet at its best (and worst), and with all likelihood, it will remain that way forever.
IRC was developed in Finland in the late 1980s. Some suggest that its purpose was to replace other networking tools of a similar ilk (for example, the talk service in UNIX). Talk is a system whereby two individuals can communicate on text-based terminals. The screens of both users split into two parts, one for received text and one for sent text. In this respect, talk operates a lot like a direct link between machines using any of the popular communications packages available on the market (Qmodem and ProComm Plus are good examples). The major difference is that talk occurs over the Internet; the connection is bound by e-mail address. For example, to converse with another party via talk, you issue a command as follows:
talk person@provider.comThis causes the local talk program to contact the remote talk daemon. If the person is available (and hasn't disabled incoming connections via talk), the screen soon splits and the conversation begins.
IRC differs from talk in that many people can converse at the same time. This was a major innovation, and IRC chatting has become one of the most popular methods of communication on the Net.
Internet warfare (that is, "hand-to-hand" combat) often occurs on IRC because IRC is lawless--a place where almost anything goes. Briefly, it works like this: Once connected to an IRC server, a user can go into a series of channels called chat spaces. Inside each channel, there is an operator, or a person who has some authority--authority, for example, to "kick" any user forwarding information that the operator deems objectionable. (Kicking is where the target is bumped from the channel and is forced to reconnect.) The operator can also ban a user from the channel, either temporarily or semi-permanently.
NOTE: IRC is one of the few places on the Internet where an individual can successfully evade even advanced detection techniques. For instance, many software pirates and crackers frequent IRC. If they are extremely paranoid, they change servers and screen names every half hour or so. Moreover, they often create their own channels instead of frequenting those already available. Finally, file transfers can be done over IRC, directly from point A to point B. No record is left of such a transfer. This differs from other types of transfers that may be closely logged. Similar types of transfers can also be made if at least one of the parties is running servers such as FTP, HTTP, or Gopher. However, IRC allows such a transfer without server software running on either box.
As you might expect, people who get kicked or banned often respond angrily. This is where combat begins. Since the introduction of IRC, dozens of munitions have been developed for use in IRC combat. They are described in the following sections.
NOTE: The first person to connect to (or create) an empty channel is automatically the operator by default. Unless he voluntarily relinquishes that authority, he has complete control of the channel and can institute kick or ban actions against anyone who subsequently joins the channel.
NOTE: Flooding can deny other users access simply because of the volume of text run through the server. It works like this: The attacker unleashes a flooding utility that generates many, many lines of text. This text is printed across the terminals of all users currently logged to the channel. Because this text saturates the write-ahead buffer of all client programs, the victims must wait for the flood to stop before they can type any further messages. Interestingly, many flood scripts actually fashion images from various text characters. If you watch such a flood for a moment, you will see some type of image develop. This activity is similar to ASCII art, which is now a popular form of artistic expression on text-based terminals that cannot display actual graphics. Of course, flooding is very irritating and therefore, few users are willing to tolerate it, even if the art that results is attractive.
Cross Reference: Read the official advisory on the Ping of Death at http://www.microsoft.com/kb/articles/q132/4/70.htm.
Cross Reference: Cisco Systems' "Defining Strategies to Protect Against UDP Diagnostic Port Denial of Service Attacks" can be found online at http://cio.cisco.com/warp/public/707/3.html.CERT Advisory CA-96.01 can be found online at ftp://ftp.cert.org/pub/cert_advisories/CA-96.01.UDP_service_denial.
Other resources exist, but most of them are shell scripts written for use on the UNIX platform. Nevertheless, I would expect that within a few months, tools programmed in GUI for Windows and Mac will crop up. Denial-of-service (DoS) attacks are infantile and represent only a slightly higher level of sophistication than e-mail bombing. The only benefit that comes from DoS attacks is that they will ultimately provide sufficient incentive for the programming community to completely eliminate the holes that allowed such attacks in the first place. In all other respects, denial-of-service attacks are neither interesting nor particularly clever. In any event, the following sections list some resources for them.
Viruses have gained so much attention in the computing community that nearly everyone knows that viruses exist. However, some users confuse viruses with other malicious files. Therefore, I thought it might be nice to quickly define the term computer virus. Once again, if you are already well aware of these basic facts, skip ahead a few paragraphs.
A computer virus is a program, sometimes (but not necessarily) destructive, that is designed to travel from machine to machine, "infecting" each one along the way. This infection usually involves the virus attaching itself to other files.
This is markedly different from a trojan horse. A trojan horse is a static entity: malicious code nested within an otherwise harmless program. Trojans cannot travel from machine to machine unless the file that contains the trojan also travels with it. A trojan is commonly a string of computer code that has been surreptitiously placed within a trusted application. That code performs an unauthorized and hidden function, one that the user would almost certainly find objectionable. (For example, mailing out the password files to an attacker in the void, or perhaps opening a back door for him. A back door is some hidden method through which an attacker can later return to the affected machine and gain control over it.)
Viruses, in contrast, replicate. Most often, this phenomenon manifests itself by the virus attaching itself to a certain class of file. For example, it is very common for viruses to attach themselves to executable files. (On the DOS/Windows platform, viruses frequently target EXE and COM files.) Once the virus is attached to a file in this manner, the victim file itself becomes a security risk. That file, when transported to another computer system, can infect still other files that may never come in contact with the original virus program.
Try to think of a virus as a living creature for a moment. Its purpose is to infect computer systems, so it stays awake at all times, listening for activity on the system. When that activity fits a certain criterion (for example, an executable file executing), the virus jumps into action, attaching itself to the active program.
TIP: Note that data file viruses now exist. At least, macro viruses should (and usually are) classified under this heading. These viruses infect data files, namely documents. These are almost nonexistent, save in the Microsoft Word and Excel environments.
If you have ever encountered a virus, you might have noticed that they are incredibly small (that is, for a program that can do so much). There is a good reason for this. Most viruses are written in a language called assembly language. Assembly language is classified in the computing community as a low-level language, meaning that it produces very small programs.
TIP: One way to tell whether a file is infected is to check its current size against the size it was when you installed it. (I wouldn't recommend using this as a method of identifying infected files, but if you find such a file using a virus checker, note the size. When you match it against the original size of the file, you will see that the file is now larger.) By subtracting the size of the virus from the file's size, you will be left with the approximate original size of the file (before it was infected).
To understand what I mean by "low-level," consider this: Computers have become quite user friendly. Today, advanced technologies allow a user to almost "talk" to a machine and get suitable answers. (Consider, for example, the new Answer wizards in Microsoft products. You can basically type out a question in plain English. The internal program routines parse your question and search the database, and out comes the answer.) This is quite a parlor trick, and gives the illusion that the machine is conversing with you.
In reality, computers speak a language all their own. It is called machine language, and it consists of numbers and code that are unreadable by a human being. The classification of a "low" or "high" language depends solely on how close (or how far) that language is from machine language. A high- or medium-level language is one that involves the use of plain English and math, expressed much in the same manner as you might present it to a human being. BASIC, Pascal, and the C programming language all fit into the medium-level class of language: You can "tell" the machine what each function is, what it does, and how it does it.
Assembly language is only one step removed from machine language and is therefore a very low-level language. And, because it speaks so directly to the machine's hardware, the resulting programs are very small. (In other words, the translation process is minimal. This is greatly different from C, where substantial translation must occur to get the plain English into machine-readable code. The less translation that has to be done, the smaller the binary that results.)
Programs written in assembly language execute with great speed, often many times faster than those written in higher-level languages. So, viruses are small, fast, and, to users who are unprepared, difficult to detect.
Cross Reference: If you want to learn more about Assembly Language, there is an excellent page on the Web that sports a search engine through which you can incisively search terms, functions and definitions. That site is http://udgftp.cencar.udg.mx/ingles/tutor/Assembler.html.
There are many different types of viruses, but one of the most critical is the boot sector virus. To get you started on understanding how viruses work, I have picked the boot sector virus as a model.
Many users are unaware of how their hard disk drive works in conjunction with the rest of the system. I want to explore that process for just a moment. Please examine Figure 14.6.
Figure 14.6.
Location of the master boot record.
Hard disks drives rely upon data stored in the master boot record (MBR) to perform basic boot procedures. The MBR is located at cylinder 0, head 0, sector 1. (Or, Logical Block Address 0. LBA methods of addressing vary slightly from conventional addressing; Sector 1=LBA 0.)
For such a small area of the disk, the MBR performs a vital function: It explains the characteristics of the disk to every other program that happens by. To do this, it stores information regarding the structure of the disk. This information is referred to as the partition table.
When a machine boots up, it proceeds, assuming that the CMOS settings are correct. These values are read and double-checked. If it finds that the default boot disk is actually 1GB when the BIOS settings suggest 500MB, there will be a problem. (The machine will not boot, and an error message will be generated.) Similarly, the RAM is tested for bad memory addresses. Eventually, when no errors have been encountered, the actual boot process begins. At that stage, the MBR takes the helm and the disk boots. When the boot sector has been infected by a virus, a critical situation develops.
NOTE: If this sounds confusing, think about when you partition a disk. DOS/Windows users do this using a program called FDISK.EXE. UNIX users also have several similar utilities, including fdisk, cfdisk, and so on. Before partitioning a disk, it is customary to examine the partition table data. (At least, you will if you want to be safe!) These programs read the partition information from the MBR partition table. This information characteristically tells you how many partitions there are, their size, and so forth. (UNIX users will even see the type of partition. DOS/Windows users cannot identify partitions not commonly used on the AT platform. Whenever these are present, the type is listed as UNKNOWN.)
As explained by the specialists at McAfee, the leading virus protection vendor:
MBR viruses are particularly insidious because they attack floppy disks whenever they are accessed by your machine. It is for this reason that MBR viruses are so commonly seen in the wild--because they infect floppies, they can travel from machine to machine fairly easily.
Cross Reference: The previous paragraph is excerpted from an article titled "Top Master Boot Record/Boot Sector Infecting Viruses," produced by McAfee Associates. This paper can be found online at http://www.mcafee.com/support/techdocs/vinfo/1101.html.
In any event, assume for the moment that you have a "clean" MBR. How does a virus manage to infect it? The infection process happens when you boot with an infected floppy diskette. Consider this situation: You decide that you are going to load a new operating system onto the drive. To do this, you use a boot floppy. (This boot floppy will contain a small boot routine that guides you through the installation.) Fine. Take a look at Figure 14.7.
Figure 14.7.
The infection illustrated.
During the boot process, the virus loads itself into memory, although generally not the upper memory. In fact, very few viruses are known to reside in upper memory. When one does, it is usually because it has piggybacked its way there; in other words, it has attached itself to an executable or a driver that always loads high. This is rare.
Once loaded into memory, the virus reads the MBR partition information. In some cases, the virus programmer has added a routine that will check for previous infection of the MBR. It checks for infection not only by his own virus, but by someone else's as well. This procedure is usually limited in scope, because the programmer wants to save resources. A virus that could check for many other viruses before installing would characteristically be larger, more easily detected, less easily transmitted, and so forth. In any event, the virus then replaces the MBR information with its own, modified version. The installation procedure is complete.
I have personal experience with just such a virus, called antiexe. A friend came to my office so I could assist him in preparing a presentation. He brought with him a small laptop that had been used at his company. Apparently, one of the employees had been playing a game on the laptop that required a boot disk. (Some games have strange memory-management routines that are not compatible with various user configurations. These typically request that you generate a boot disk and undertake other annoying procedures.) Through a series of unfortunate events, this virus was transferred from that laptop to one of my machines. The curious thing is this: I did have a terminate-and-stay-resident (TSR) virus checker installed on the infected machine. This was a well-known product, but I will not mention its name here lest I cause a panic. For some inexplicable reason, the TSR virus checker did not catch antiexe when it infected my MBR, but only after the machine was rebooted a day or so later. At any rate, I woke to find that my machine had been infected. Antiexe is described in the CIAC database as follows:
NOTE: The majority of boot sector viruses also contain some provision for storing the original MBR elsewhere on the drive. There is a good reason for this. It isn't because the virus programmer is a nice person and intends to eventually return the MBR to its original state. Rather, it is because he has to. Many important functions require that the MBR be read on initialization. Typically, a virus will keep a copy of the original and offer it up whenever other processes request it. In this way, the virus remains hidden because these functions are never alerted to the fact that the MBR was in any way altered. Sneaky, right? When this technique is used correctly, it is referred to as stealth.
Most viruses do not actually destroy data; they simply infect disks or files. There are, however, many occasions on which infection alone is enough to disrupt service; for example, some drivers operate erratically when infected. This is not to say, however, that there are no destructive viruses.
Who writes viruses? Many different types of programmers from many different walks of life. Kids are a common source. There are kits floating around on the Internet that will assist budding programmers in creating viruses. It has been theorized that young people sometimes write viruses to "make their mark" on the computing communities. Because these young people do not actually work in computer programming, they figure that writing a virus is one way to make a name for themselves. (A good percentage of virus authors take a pseudonym or "handle" and write under that. This moniker is sometimes found within the code of the virus.)
One interesting aspect of the virus-writing community is that vanity, envy, and fierce competition often influence the way such viruses are written. For example:
Cross Reference: There is a fascinating paper on the Internet regarding the rise of virus- development groups in Eastern Europe that describes how the virus took these programming communities by storm. Ultimately, bulletin board systems were established where virus authors could exchange code and ideas. The paper is extremely thorough and makes for absorbing reading, giving a bird's eye view of virus development in a noncapitalist environment. It is called "The Bulgarian and Soviet Virus Factories"; it was written by Vesselin Bontchev, Director of the Laboratory of Computer Virology at the Bulgarian Academy of Sciences in Sofia, Bulgaria. The paper can be found at http://www.drsolomon.com/ftp/papers/factory.txt.
As I have already noted, many programmers develop viruses using virus kits, or applications that are designed specifically to generate virus code. These kits are circulated on the Internet. Here are the names of a few:
Cross Reference: The preceding paragraph is excerpted from an article by Vesselin Bontchev (a research associate at the Virus Test Center at the University of Hamburg) titled "Are `Good' Computer Viruses Still a Bad Idea?" This paper can be found online at http://www.virusbtn.com/OtherPapers/GoodVir/.
Reportedly, the first virus ever detected in the wild emerged in 1986. It was called the Brain virus. According to the CIAC Virus Database at the U.S. Department of Energy, the Brain virus was a memory-resident boot sector virus:
NOTE: A virus is deemed in the wild when it has escaped or been released into the general population. That is, the wild refers to any computing environment outside the academic or development environment where the virus was created and tested. This term is purportedly derived from lingo used in reference to environments where biological warfare experiments are conducted. These studies are typically conducted under controlled circumstances, where no danger is posed to the surrounding communities. However, when a biological virus escapes its controlled environment, it is deemed to have entered the wild. Today, computer virus researchers refer to the Internet (or any publicly accessible computing environment) as the wild.
Since then, innovations in virus technology have caused these creatures to become increasingly complex. This has led to classifications. For example, there are basically three types of virus:
Most often, file viruses infect only a particular class of file--usually executable files. COM and EXE files are good examples. File viruses, however, are not restricted to executables; some will infect overlay files (OVL) or even system driver files (SYS, DRV).
It is estimated that there are currently more than 7,000 file viruses on the DOS platform alone. As you might expect, virus authors are eager to write file viruses because of how far these can spread. Given 10 days on a computer system, a file virus can effectively infect the majority (or perhaps even all) of the executable files on the hard disk drive. This is due to the manner in which file viruses operate. (See Figure 14.8.)
NOTE: Do you remember that I explained that viruses are rarely found in upper memory? When such viruses are found, they are usually riding on a driver, such as a SYS or DRV file. PC users who worked extensively with the DOS/Windows combination will remember various drivers that required an upper-memory load.
Figure 14.8.
Normal operation and execution of a program.
Under normal operations (on a noninfected machine), a command is executed and loaded into memory without event. (This could equally be a COM file. In Figure 14.8, I just happened to have used the .EXE extension.) When a file virus is present, however, the process is complicated because the virus now intercepts the call. (See Figure 14.9.)
Figure 14.9.
Loading a program with a file virus present.
First, the virus temporarily intercepts the process for long enough to infect the program file. After infecting the program file, the virus releases its control over the system, returning the reins to the operating system. The operating system then loads the infected file into memory. This process will be repeated for each file loaded into the system memory. Stop and think for a moment about this. How many files are loaded into memory in the course of a business day? This is how file viruses ultimately achieve systemic infection of the system.
In addition to the classifications of viruses, there are also different types of viruses. These types are derived from the manner in which the virus operates or what programming techniques were employed in its creation. Here are two:
If you are a system administrator, I have different advice. First, it is true that the majority of viruses are written for the IBM-compatible platforms (specifically, platforms on which users run DOS, Windows, Windows NT, and Windows 95). If your network is composed of machines running these operating systems and you offer your users access to the Internet, you have a problem.
There is no reliable way to restrict the types of files that your users download. You can institute policies that forbid all downloads, and your users will probably still download a file here and a file there. Human nature is just that way. Therefore, I would recommend that you run memory-resident virus scanners on all machines in the domain, 24 hours a day. (At the end of this section, you will find some resources for obtaining such products.)
To learn more about how viruses work, you should spend some time at a virus database on the Internet. There are several such databases that provide exhaustive information on known viruses. The most comprehensive and useful site I have ever found is at the Department of Energy.
The list is presented in alphabetical order, but can be traversed by searching for platform. You will instantly see that most viruses were written for the Microsoft platform, and the majority of those for DOS. What you will not see are any known in-the-wild viruses for UNIX. However, by the time this book is printed, such information may be available. There is talk on the Internet of a virus for the Linux platform called Bliss.
Cross Reference: Find the Department of Energy site online at http://ciac.llnl.gov/ciac/CIACVirusDatabase.html.
Reports on Bliss at the time of this writing are sketchy, but it appears that Bliss is a virus. There is some argument on the Internet as to whether Bliss qualifies more as a trojan, but the majority of reports suggest otherwise. Furthermore, it is reported that it compiles cleanly on other UNIX platforms.
It is extremely unlikely that your box would be infected. The author of the program took steps to prevent all but experienced programmers from unpacking and using this virus. However, if you should discover that your machine is infected with this new virus, you should immediately submit a report to Usenet and several bug lists, describing what, if any, damage has been done to your system.
Cross Reference: The only known system tool that checks for Bliss infection was written by Alfred Huger and is located online at ftp://ftp.secnet.com/pub/tools/abliss.tar.gz.
I would like to explain why the majority of viruses are written for personal computer platforms and not for UNIX, for example. In UNIX (and also in Windows NT), great control can be exercised over who has access to files. Restrictions can be placed on a file so that user A can access the file but user B cannot. Because of this phenomenon (called access control), viruses would be unable to travel very far in such an environment. They would not, for example, be able to cause a systemic infection.
In any event, viruses do represent a risk on the Internet. That risk is obviously more relevant to those running DOS or any variant of Windows. Following are some tools to keep your system safe from virus attack.
Conversely, perhaps you have some old machines lying around that run early versions of this or that operating system. On such systems, you may not be able to run Windows 95 or Windows NT software. To present you with a wide range of choices, I suggest that you go to one of the following sites, each of which has many, many virus utilities:
Robert Slade's Guide to Computer Viruses : How to Avoid Them, How to Get Rid of Them, and How to Get Help (Second Edition). Springer. 1996. ISBN 0-387-94663-2.
Virus: Detection and Elimination. Rune Skardhamar. AP Professional. 1996. ISBN 0-12-647690-X.
The Giant Black Book of Computer Viruses. Mark A. Ludwig. American Eagle. 1995.
1996 Computer Virus Prevalence Survey. NCSA National Computer Security Association. (Very good.)
The Computer Virus Crisis. Fites, Johnson, and Kratz. Van Nostrand Reinhold Computer Publishing. ISBN 0-442-28532-9. 1988.
Computer Viruses and Related Threats: a Management Guide. National Technical Information Service (NTIS). PB90-115601CAU.
A Passive Defense Against Computer Viruses. Frank Hoffmeister. Proceedings of the IASTED International Symposium Applied Informatics. pp. 176-179. Acta Press. 1987.
PC Security and Virus Protection: the Ongoing War Against Information Sabotage. Pamela Kane. M&T Books. ISBN 1-55851-390-6. 1994.
How Prevalent are Computer Viruses? Jeffrey O. Kephart and Steve R. White. Technical Report RC 17822 No78319. Watson. 1992.
A Short Course on Computer Viruses (Second Edition). Frederick B. Cohen. Series title: Wiley Professional Computing. John Wiley & Sons. 1994. ISBN 1-471-00769-2
A Pathology of Computer Viruses. David Ferbrache. Springer-Verlag. ISBN 0-387-19610-2; 3-540-19610-2. 1992.
The Virus Creation Labs: A Journey into the Underground. George Smith. American Eagle Publications. ISBN 0-929408-09-8. Also reviewed in Net Magazine, February 1996.
Viruses in Chicago: The Threat to Windows 95. Ian Whalley, Editor. Virus Bulletin. Abingdon Science Park, England.
Computer Virus Help Desk. Courtesy of the Computer Virus Research Center. Indianapolis, Indiana. European Institute for Computer Anti-Virus Research. Future Trends in Virus Writing. Vesselin Bontchev. Virus Test Center. University of Hamburg. A Biologically Inspired Immune System for Computers. Jeffrey O. Kephart. High Integrity Computing Laboratory, IBM. Thomas J. Watson Research Center. Dr. Solomon's Virus Encyclopedia. An Overview of Computer Viruses in a Research Environment. Matt Bishop. Washington, D.C.: National Aeronautics and Space Administration. Springfield, Va. Distributor: National Technical Information Service. 1991. Internet Computer Virus and the Vulnerability of National Telecommunications Networks to Computer Viruses. Jack L. Brock. November 1988. GAO/T-IMTEC-89-10, Washington, D.C., 20 July 1989. Testimonial statement of Jack L. Brock, Director, U. S. Government Information before the Subcommittee on Telecommunications and Finance, Committee on Energy and Commerce, House of Representatives.A Guide to the Selection of Anti-Virus Tools and Techniques. W. T. Polk and L. E. Bassham. National Institute of Standards and Technology Computer Security Division.
© Copyright, Macmillan Computer Publishing. All rights reserved.